Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 003 / db3anom.arc / DB3ANOM.TXT

Wrap

Text File | 1986-03-28 | 76.9 KB | 2,349 lines

- Locating dBASE III Anomalies and Workarounds - ( from the Source - Ashton Tate SIG - ATSIG ) 108 item(s) found for ALL title: USING SUSPEND WITH ON (DEVELOPER'S RELEASE) version: DR date: 10 Mar 1986 text: Using the SUSPEND command with the ON command in a program may cause some unexpected results. The command: ON KEY SUSPEND in a program will return the error message, "Valid only in programs" when a key is pressed. The program, however, will be SUSPENDed. The command: ON ERROR SUSPEND behaves erratically. It will SUSPEND the program, although RESUME may have to be entered twice before the program actually resumes execution. title: SET FILTER TO EXPRESSION IN PARENTHESIS (DEVELOPER'S RELEASE AND RUNTIME+) version: DR date: 10 Mar 1986 text: If a SET FILTER TO command has a parenthesis following the TO and is encrypted using DBC.COM, that command line will produce the error message "Invalid function name" when it is run from dBRUN or dBASE III Developer's Release. The command: SET FILTER TO (F1 = 2 .OR. F2 = 2) .AND. F3 > 1 will produce this error when encrypted and run. To work around, build the FILTER expression by placing the simplest non-grouped subexpression first and then begin the grouped subexpressions. For example: SET FILTER TO F3 > 1 .AND. (F1 = 2 .OR. F2 = 2) title: IIF() NESTTING LIMITATION (DEVELOPERS'S RELEASE) version: DR date: 10 Mar 1986 text: There is a limit to the number of times IIF() may be nested. Nesting this function eight or more deep will return a zero instead of the designated value. title: SORT IGNORES EXTENSION OF RESULTANT DATABASE version: 10 11 DR date: 10 Mar 1986 text: SORTing to a file with an extension other than .DBF will result in the extension being ignored and a .DBF extension given to the new file. For example: SORT ON Field1 TO Newfile.NEW will create Newfile.DBF. title: SET TALK ON HAS PRECEDENCE OVER SET CONSOLE OFF version: 10 11 DR date: 10 Mar 1986 text: For commands that produce a running total or a final result, such as INDEX or COUNT, the SET TALK ON command takes precedence over the SET CONSOLE OFF command so that the results of TALK will be displayed when SET CONSOLE is OFF. The following routine demonstrates this. SET TALK ON SET CONSOLE OFF USE Test COUNT TO memvar <--- The results of COUNT display. ? memvar <--- This is suppressed by SET TALK OFF. The SET CONSOLE OFF command in the Developer's Release of dBASE III does suppress the results of SET TALK ON in all cases. title: @ <ROW>, <COL> WITH NO ARGUMENTS version: 10 11 DR date: 10 Mar 1986 text: An @...SAY statement sent to the printer with no argument and a row coordinate greater than 24 will return the error message "SAY/GET position is off the screen." For example, SET DEVICE TO PRINT @ 25,0 The @ <row>, <col> command with no argument clears that row on the screen beginning at the column position, regardless of the status of SET DEVICE TO. Be sure that any @...SAY directed to the printer has an argument. title: CTRL-K-R IN MODIFY COMMAND version: 10 11 date: 10 Mar 1986 text: When using the Ctrl-K-R in the dBASE III word processor, there is a limit of fifteen characters to the name of the file being imported. If the name of the file, including drive designator and path, is sixteen characters or longer, problems will occur. The computer may freeze with the message "File does not exist (Hit SPACE)" being displayed; or the error message "*** STACK OVERFLOW ***" appears and the user is returned to PC/MS-DOS. For example, the filenames: B:\A\Data10.TXT B:\Datapath\One are acceptable, while B:\A\Data101.TXT <-- "File does not exist (Hit SPACE)" B:\Datapath\File <-- "*** STACK OVERFLOW ***" are not. In the Developer's Release, MODIFY COMMAND will support filenames including paths exceeding sixteen characters. title: DO PROGRAM CAUSES RETURN POINTERS TO BE LOST version: 10 11 date: 10 Mar 1986 text: Executing a command file with the same name as a procedure in a procedure file that has been opened and closed causes return pointers to be lost. For example, if a file has a nested DO WHILE, RETURNing from the subprogram will cause the controlling DO WHILE loop to terminate abnormally. The program below demonstrates this problem. *--- Test.PRG DO WHILE .T. SET PROCEDURE TO Testa DO Test1 <-- From Testa.PRG. CLOSE PROCEDURE DO Test1 <-- Separate command file ENDDO <-- will terminate although no EXIT or RETURN has been executed. This problem has been corrected in the Developer's Release of dBASE III. title: BROWSE WHEN APPENDING version: 10 11 DR date: 10 Mar 1986 text: When APPENDing new records with the BROWSE command, dBASE III will not automatically pan right to allow data entry to fields that are off the screen. Instead, the cursor will drop to the next line and dBASE III will start to enter another record. Use Ctrl-B and Ctrl-F to pan left or right, respectively, while APPENDing. title: INDEX ON SUBSTR( <FIELD>, N, LEN( <FIELD> ) version: 10 11 date: 10 Mar 1986 text: INDEXing a database file with a key expression that includes the LEN() function as the second argument of the SUBSTR() function will result in a nonfunctional index file. For example: INDEX ON SUBSTR( <Field>, 1, LEN( <Field> ) ) TO; Indexfile will create an index file that appears to be correctly constructed. You can FIND or SEEK a record and then EDIT it. The index file, however is not updated and any attempt to GOTO a record or BROWSE will return the error message "Record not in index." The problem is corrected in the Developer's Release. title: DO <PROCEDURE> CANNOT CONTAIN SPECIAL CHARACTERS version: 10 11 DR date: 10 Mar 1986 text: In dBASE III, PROCEDURE names cannot contain special characters, although filenames can. If the name of a PROCEDURE within a PROCEDURE file contains a special character ($, #, -, @, etc.), using the DO <procedure> command will return the error message "Unrecognized phrase/keyword in command." For example: *--- Proc-test.PRG PROCEDURE Test-it ? 'This is Test-it from Proc-test.PRG' RETURN * EOP Proc-test.PRG *--- Test.PRG SET PROCEDURE TO Proc-test <--- This works properly. DO Test-it <--- This returns the error RETURN message. * EOP Test.PRG Note that this applies only to PROCEDURE names and not to command files names. This may be a problem if you have recently merged command files into a procedure file and your command filenames contain special characters. title: INDEX ON STR() version: 10 11 date: 10 Mar 1986 text: (1) Attempting to INDEX ON the concatenation of many STR() functions may create an index that is in record number order. Specifically, if the length of the key expression is 80 or 90 characters long and consists solely of a concatenation of STR() functions, the resultant index file will be in the same order as the database file. For example: . USE Numfile . LIST RECORD# NUM1 NUM2 NUM3 NUM4 NUM5 NUM6 NUM7 NUM8 1 8 8 8 8 8 8 8 8 2 7 7 7 7 7 7 7 7 3 6 6 6 6 6 6 6 6 4 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 6 3 3 3 3 3 3 3 3 7 2 2 2 2 2 2 2 2 8 1 1 1 1 1 1 1 1 . INDEX ON STR(Num1,1)+STR(Num2,1)+STR(Num3,1)+STR(Num4,1) +STR(Num5,1)+STR(Num6,1)+STR(Num7,1)+STR(Num8,1) TO Numex * The key expression in this example is 96 characters long. * The expected result is that the records will be in * reverse record number order when the index Numex is used. . LIST RECORD# NUM1 NUM2 NUM3 NUM4 NUM5 NUM6 NUM7 NUM8 1 8 8 8 8 8 8 8 8 2 7 7 7 7 7 7 7 7 3 6 6 6 6 6 6 6 6 4 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 6 3 3 3 3 3 3 3 3 7 2 2 2 2 2 2 2 2 8 1 1 1 1 1 1 1 1 The database file has been indexed in record number order and is identical to the unindexed file. (2) The maximum length of key expression is 100 characters. In the example above, the key expression is 96 characters long which is within the limitation. The maximum length of the key itself is also 100 characters. In the example above, the key is 8 characters long, one character for each field. If either the key or the key expression exceeds the 100 character limitation, dBASE III will normally return the error message "Index is too big (100 char maximum)". However, this error is not trapped if the key expression is formed by the concatenation of STR() functions. The INDEX command given in the paragraph above may be lengthened as in the following example and no error message will result. INDEX ON STR(Num1,1)+STR(Num2,1)+STR(Num3,1)+STR(Num4,1) +STR(Num5,1)+STR(Num6,1)+STR(Num7,1)+STR(Num8,1)+STR(Num 1,1) TO Numex The key expression in this command is 108 characters in length. No error message is returned when this command is executed, but one of two errors will occur. Either the index that is created is still in record number order as explained in the first paragraph, or dBASE III will return random error messages as it attempts to create the index. Because this is not trapped, pay extra attention when you create index files from a long expression consisting of the concatenation of STR() functions. title: RETURN TO MASTER version: 10 11 date: 10 Mar 1986 text: RETURN TO MASTER will not work properly if it is used in a PROCEDURE which is called from within a DO WHILE loop with the MASTER as the calling program. Specifically, the program will stop execution upon RETURNing TO the MASTER file. However, pressing Esc will allow the user to return to the dBASE III dot prompt. For example: * Test.PRG PUBLIC one one = "Y" SET PROCEDURE TO Test1 DO WHILE one = "Y" DO Pro_3 ? "Back IN Test.PRG" ENDDO CLOSE PROCEDURE RETURN * Test1.PRG PROCEDURE Pro_3 ? "Now in Pro_3 PROCEDURE in Test1 file" RETURN TO MASTER If RETURN TO MASTER is changed to RETURN, the command file works properly. If Test.PRG were to call another file which then called the procedure file, RETURN TO MASTER will work. title: ZAP, PACK, AND INDEX FILES version: 10 11 DR date: 10 Mar 1986 text: PACKing or ZAPping a database file without its index files in use, then opening the index files and adding records to the file will result in multiple record entries in the index files. For example, the following command sequence will result in an index file with two entries for each record in the database file: USE File_one INDEX Alpha COPY TO New_file CLOSE INDEX ZAP SET INDEX TO Alpha APPEND FROM New_file Ideally, opening the index file after the file has been ZAPped should be trapped by an error message, such as "End of file encountered unexpectedly" or "Record out of range". title: USE version: 10 11 DR date: 10 Mar 1986 text: An attempt to use the PC/MS-DOS directory navigation path (..) in a USE command will give unexpected results. USEing the database will make the file active, but there will be no ALIAS. An attempt to USE another database file in another SELECT area using the same technique, will cause the error message "ALIAS name already in use" to be displayed. * ---Open first database file. USE ..\nme\Budget DISPLAY STATUS Currently selected database: Select area - 1, Database in use: C:..\nme\Budget.dbf Alias - * ---Open another database file. SELECT 2 USE ..\nme\Sumfrm ALIAS name already in use ? USE ..\nme\sumfrm If an ALIAS is assigned in both USE commands, no error results. If you need to avoid specifying the full path name, use the RUN command to log the previous directory and then specify the datafile to USE. For example, RUN CD .. USE nme\Budget SELECT 2 USE nme\Sumfrm title: TYPE version: 10 11 date: 10 Mar 1986 text: If you attempt to use the following syntax for the TYPE command: TYPE <File> TO SCREEN it will be trapped as an error and give the message, "File does not exist". Subsequent attempts to USE or MODIFY the text file that you wanted to TYPE will return the error message, "File is already open." CANCEL or CLEAR ALL will not close the file. QUITting and re-entering dBASE III is the only option. The problem is fixed in the Developer's Release. You will receive the expected error message, "Syntax error" and the file being TYPEd will remain properly closed. title: TRIM() WITH LIST OR DISPLAY version: 10 11 DR date: 10 Mar 1986 text: TRIM() will not work with the LIST or DISPLAY commands when the the function is the last portion of an expression in an expression list, or the TRIM() is the last portion of an expression followed by a concatenation of spaces. For example: LIST TRIM(Name), Address ^__________________ (note TRIM() is just before the comma) LIST TRIM(Name) + ' ' , Address ^-----------(note TRIM() is followed by a space then the comma) TRIM will work, however, when not in the last position of the expression list. For example: LIST TRIM(Name) + ' ' + Address, City title: SUSPEND (DEVELOPER'S RELEASE) version: DR date: 10 Mar 1986 text: If you SUSPEND a command file and restart it with DO <filename> instead of RESUME, dBASE III opens the file again, without closing the previous session. The expected error message "File is currently open" does not appear. As each file remains open, this will eventually produce "Too many files are open." Issuing the CANCEL command will close every instance of the open file. This problem is most likely to occur if you are debugging a command file and forget that you are still in SUSPEND. It is always advisable to RESUME before calling any command file if you are in the midst of a programming and debugging session. title: SUM TO AND PUBLIC MEMORY VARIABLES version: 10 11 date: 10 Mar 1986 text: Attempting to SUM TO memory variables that have been declared as PUBLIC will usually result in erroneous data. Initializing the variables before the SUM command will sometimes, but not always, correct the error. In addition to this problem, there is a practical limit to the number of expressions that may be used in one SUM command. In order to use the SUM command reliably, follow these rules. 1. Do not SUM TO memory variables that are PUBLIC. Instead, use PRIVATE variables and STORE the results of the SUM to PUBLIC variables. 2. Limit the number of expressions in the SUM command to three or less. title: SUM PRODUCES LINEFEEDS version: 10 11 date: 10 Mar 1986 text: The SUM and AVERAGE commands send two linefeeds to both the screen and printer. For example, the following command file will output two extra linefeeds: SET TALK OFF SET PRINT ON ? "Income" SUM Income TO inc ? inc SET PRINT OFF OUTPUT: Income <--+ Two extra linefeeds. <--+ 17384805.00 The only workaround for screen output is to SET CONSOLE OFF when executing a SUM or an AVERAGE, and SET CONSOLE ON when done. For printer output you can use SET PRINT OFF before the command and SET PRINT ON afterward. title: STORE LARGE NUMERIC version: 10 11 date: 10 Mar 1986 text: Attempting to STORE a number with more than 43 digits to a memory variable will hang the computer and require a warm boot (that is, Ctrl-Alt-Del). More than 60 digits will require a cold boot (that is, restarting the system. title: STORE version: 10 11 date: 10 Mar 1986 text: STOREing 254 characters to a memory variable will eventually give the "Out of memory variable memory" error message even though DISPLAY MEMORY shows that there is memory space available. With MVARSIZ at the default setting, this seems to occur after the 23rd attempt to STORE to the memory variable. Increasing the MVARSIZ will allow more STORE commands, but will eventually produce this error. For example, the following set of commands will produce the message after 23 iterations, with MVARSIZ set at the default. CLEAR MEMORY DO WHILE .T. STORE SPACE( 254 ) TO memvar ENDDO title: SORT WITH 66 RECORDS version: 10 11 date: 10 Mar 1986 text: SORTing a file that has more than 66 records in such a way that the resulting file has exactly 64 records will produce a file in which the first record is corrupted. title: SORT FOR SUBSTR() version: 10 11 date: 10 Mar 1986 text: Attempting to SORT FOR SUBSTR(fieldname,n,n) = <value> will return "00% Sorted *** STACK OVERFLOW ***", dropping the user out of dBASE III to the operating system. title: SORT FOR A RANGE OF DATES version: 10 11 date: 10 Mar 1986 text: Attempting to SORT only a subset of a database file based on a single date or a range of dates may cause a problem if the following form is used: SORT ON <exp> TO <file> FOR DTOC(date)="99/99/99" where the 9's represent any date. The error message that will result is: 00% Sorted *** STACK OVERFLOW *** and you will be dropped out of dBASE III to the operating system. To prevent this problem, use the following form. SORT ON <exp> TO <file> FOR date=CTOD("99/99/99") This work-around will not work for blank dates. The sort will appear to execute normally, but no records will be written to the target file. title: SORT version: 10 11 DR date: 10 Mar 1986 text: (1) Attempting to SORT a file with SET FILTER TO SUBSTR(fieldname,n,n) = <value> will return a "*** STACK OVERFLOW ***" and drop you out of dBASE III to the operating system. [1.0, 1.1] (2) SORTing a database file from a command file that is nested 13 levels deep will fail with a system crash. The SORT command will return a status message stating that a percentage of the records in the original file were SORTed, but then the computer will freeze with no error message or warning. [1.0, 1.1, D.R.] (3) Attempting to use the command SORT TO <Filename> ON <Fieldname> with a RELATION SET produces the error message "*** STACK OVERFLOW ***" and will drop you out of dBASE III to the operating system prompt. This will not occur if the RELATION is SET to RECNO(). [1.0, 1.1] (4) One cannot SORT to a file in a directory other than the current one. An attempt to do this will not produce an error message and will not create the designated file. Instead, a file name W44 will be created in the current directory of the default drive. [1.0, 1.1] (5) The effective limit of SORT is in the 32,000 record range. SORTing a file with more than 32,000 records will produce the following error messages: nn% Sorted Records do not balance...(PROGRAM ERROR) 100% Sorted The SORTed file will not contain all the records from the original. The workaround for sorting databases in excess of 32,000 records is to INDEX and then COPY. The procedure is as follows: USE <filename> INDEX ON <sort key> to Temp COPY TO Sorted [1.0, 1.1] title: SET RELATION TO version: 10 11 date: 10 Mar 1986 text: The command syntax SET RELATION INTO <file> TO <key> will not SET the RELATION although no error message is displayed and DISPLAY STATUS shows the RELATION as SET. The SET RELATION command is sensitive to the order that the INTO and the TO clauses are specified. Apparently, everything after the INTO clause is ignored. Be sure to check that you have specified the TO clause before the INTO clause if your RELATIONs appear to fail. title: SET ORDER TO (DEVELOPER'S RELEASE) version: DR date: 10 Mar 1986 text: SET ORDER TO 0 or <space> is intended to cause the database file to act in physical, unindexed order, while maintaining the integrity of the open indexes. However, the indexes are not updated if the key field is changed. For example: USE <Filename> INDEX <Index1>, <Index2> SET ORDER TO EDIT <------ Change key field for Index1.NDX SET ORDER TO 1 will produce the error message "Record is not in index." title: SET HISTORY TO (DEVELOPER'S RELEASE) version: DR date: 10 Mar 1986 text: The SET HISTORY TO command is documented as having a 16,000 command line limit. However, there are a number of problems that can occur when a large number is used as its argument. 1. There is no way to escape from a LIST HISTORY. If you SET HISTORY TO a large number, enter a large number of commands, and LIST HISTORY, the computer may be tied up for some time as the entire contents of HISTORY scroll by. Pressing Esc will not interrupt the LIST. 2. HISTORY appears to use memory without limit. If you SET HISTORY TO is a large number, it is possible to use all the available memory. So much memory may be used that it is impossible to return to the operating system level. The error message: Memory allocation error Cannot load COMMAND, system halted appears if you attempt to QUIT in such as case. Setting MAXMEM higher than the default will delay, but not prevent the problem. Furthermore, the dBASE III Reference Manual implies that -------------------------- HISTORY respects the MAXMEM setting by stating that the RUN command may overwrite the HISTORY stack unless MAXMEM is set higher than 256K. However, HISTORY appears to reserve memory beyond MAXMEM. If the number of commands to store in HISTORY is SET high and HISTORY contains many entries, attempting the RUN command will return the error message, "Insufficient memory." 3. There is no error trapping on the upper limit of HISTORY and so it is possible to SET it to values higher than 16,000. Values less than 1,000,000 appear to work properly, although it is not known if more than 16,000 lines of code are stored. When the value of HISTORY exceeds 1,000,000, the HISTORY buffer is corrupted. Any attempt to DISPLAY or LIST HISTORY will display graphic characters to the screen and the computer may freeze. title: SET FUNCTION, LIMIT OF 30 CHARACTERS version: 10 11 date: 10 Mar 1986 text: The maximum number of characters (including semicolons) that can be programmed into a function key is 30. Exceeding this limitation is not trapped as an error. Instead, the extra characters wrap into the next function key. This problem will also cause an incorrect display of the function key values in full-screen SET. title: SET FORMAT TO <FILENAME> version: 10 11 DR date: 10 Mar 1986 text: Issuing an APPEND, CHANGE, EDIT, or READ command when the open format file does not match the current database will lock the computer. title: SET FILTER TO WITH GO TOP version: 10 11 DR date: 10 Mar 1986 text: After a SET FILTER TO is issued, it may be necessary to issue a GO TOP. Otherwise, the first record in the file may fall through (that is, it may not be filtered out) even if it does not satisfy the filter condition. The commands that do not require a GO TOP are those that automatically rewind the database file before executing (that is, any command whose default scope is ALL). These include AVERAGE, COUNT, LIST, and SUM. The commands that allow the first record to fall through are those that have a scope of NEXT <n>. These include ?/??, @...SAY, BROWSE, and DISPLAY. title: SET FILTER TO WITH GO BOTTOM version: 10 11 DR date: 10 Mar 1986 text: If a SET FILTER TO condition is not satisfied by any records in the database file and a GO BOTTOM is issued, both the EOF() and BOF() will return a true (.T.). Removing the filter by issuing a SET FILTER TO does not reset EOF() or BOF(). The record pointer must be repositioned to reset EOF() and BOF(). SKIP or SKIP -1, however, will return a file boundry error message, because EOF() and BOF() are true. To move the record pointer appropraitely issue a GO TOP and the BOF() and EOF() values will be reset to false (.F.). title: SET EXACT ON AND INOPERABLE INDEXES version: 10 11 date: 10 Mar 1986 text: SET EXACT ON will render indexes inoperable when the length of the key expression is not a multiple of four. SEEK and FIND will return "No find" even if the string is in the file. Any attempt to access an individual record will return "Record is not in index". Commands that return this message are GOTO <n>, EDIT <n>, and <n>, where <n> represents the record number. One work-around for this is to MODIFY STRUCTURE and adjust the length of the key field to a multiple of four. Another work-around is to recreate the index and add spaces to the end of the index key expression to bring it to a multiple of four. For example, the following index is created with the character field, Code, of width six: INDEX ON Code + SPACE(2) TO Codendx The above key expression, Code + SPACE(2), will evaluate to an index key of eight characters which is a multiple of four. title: SET ESCAPE ON/OFF version: 10 11 DR date: 10 Mar 1986 text: Ctrl-S will not pause scrolling in dBASE III if ESCAPE is SET OFF. title: SET DELIMITERS ON version: 10 11 date: 10 Mar 1986 text: If you SET DELIMITERS ON, then CREATE or MODIFY a database file structure, pressing Esc without making any changes will SET DELIMITERS OFF. title: SET CARRY ON version: 10 11 DR date: 10 Mar 1986 text: If records are added to a database file with SET CARRY ON and the last record in the file is marked for deletion, the new records will also be marked for deletion. This is true for adding records with APPEND and BROWSE. title: SET (FULL-SCREEN), USING THE PATH OPTION version: 10 11 date: 10 Mar 1986 text: Under the Disk heading in full-screen SET, the DISK DRIVE SEARCH PATH is used to set the internal dBASE III path. If this path has already been set in Config.DB or by using the dBASE SET PATH command, the path name will show up when this option is selected. However, when either Return or Esc is pressed at the selection, the path name will be erased. Therefore, if you select the Path option and do not wish to change it, you must re-enter the path name. An alternate way to view the internal dBASE III path name is to use DISPLAY STATUS. title: SET (FULL-SCREEN), USING THE INDEX OPTION version: 10 11 date: 10 Mar 1986 text: Under the Files heading in full-screen SET, there is an option to open INDEX files. This option neglects to open the selected index files when used and it will also close all active index files in the currently selected work area. title: ROUND() version: 10 11 date: 10 Mar 1986 text: The ROUND() function will not round negative numbers correctly. You can use the following procedures to round off a negative number: PROCEDURE Abs {Absolute value} PARAMETERS inval, sign, outval IF inval < 0 sign = (-1) outval = (-inval) ELSE sign = 1 outval = inval ENDIF RETURN PROCEDURE Round {Round a positive or negative number} PARAMETERS inval, outval sign = 1 DO Abs WITH inval, sign, outval outval = sign * ( INT( ( outval * 100 ) + .5 ) / 100.00 ) RETURN Round is used in conjunction with Abs in rounding a number. Round will round a number to two decimal places. An example of how the above procedures would be used is given below. * ---Assumes Math.prg contains Abs and Round. SET PROCEDURE TO Math INPUT "Enter number to round :" TO number result = 0.0 DO Round WITH number, result ? result CLOSE PROCEDURE title: RETURN TO MASTER version: 10 11 date: 10 Mar 1986 text: title: REPORT FORM AND MODIFY REPORT version: 10 11 date: 10 Mar 1986 text: (1) A REPORT FORM that is defined with a report width and a left margin whose difference is exactly 256 causes dBASE III to display garbage on the screen and/or printer and will require a warm boot (that is, Ctrl-Alt-Del). Increasing the width of the report or decreasing the left margin so that their difference is greater than 256 corrects this problem, but the report title will display on several lines instead of just one. A difference of 255 or less will properly display the report. (2) MODIFY REPORT will allow the number of decimal places to be changed from the default. If this is done and the report is run, everything is as expected. However, if the report is modified again, the number of decimal places reverts to the default when the cursor reaches the "# decimal places" field. title: REPORT FORM WITH STACKED COLUMNS version: 10 11 DR date: 10 Mar 1986 text: CREATEing a REPORT FORM field that consists of stacked columns built with the result of the STR() function and numeric fields may cause numbers to display incorrectly. Specifically, entering: STR( Field1, 5 ) + STR( Field2, 5 ) in the field contents and specifying a column width of five will result in a correct display only when the fields have five-digit numbers stored in them. If the number has less than five digits, the display will be misplaced by the number of digits missing. The example above will produce: 11111 11111 if the fields are full, but: 1111 1111 1111 if there are only four digits in the fields. title: REPORT FORM WITH RIGHT MARGIN=REPORT WIDTH version: 10 11 date: 10 Mar 1986 text: CREATEing a REPORT FORM with a right margin value equal to the report width (the page width minus the left margin) will display garbage to the screen or printer. This happens beacuse there is no space to print the report. There is a general misconception about the meaning of the right margin in the REPORT FORM. Some users have the impression that its value is the number of characters from the left margin, much the same way a typewriter works. The value actually refers the the number of characters the right margin is offset from page width. For example, page width |------------------------------------->| right margin |<----------| title: REPORT FORM WITH MULTIPLE LINE HEADINGS version: 10 11 date: 10 Mar 1986 text: There is a problem with the REPORT FORM command in printing multiple line headings. Sometimes when printing a combination of character and numeric information, the second and third lines of the column headings get shifted to the left. There is no known work-around for this problem. title: REPORT FORM version: 10 11 DR date: 10 Mar 1986 text: (1) When using a REPORT FORM to print a Memo field that is longer than one page, the field will print continuously on the report with no page breaks. [1.0, 1.1, D.R.] (2) If the NOEJECT option of the REPORT FORM is used, and the report does not fill the last page, the line counter is not reset to zero. Therefore, when the next report is printed, the first page of this report will print an incorrect number of lines. [1.0, 1.1, D.R.] (3) REPORT FORMs with two levels of subtotals that use the eject after subtotals option will format the first page of the report differently than all other pages. The difference is very slight, but the first page shows the subgroup heading on the line directly below the major group. All other pages have a blank line between the subgroup and the major group headings. [1.0, 1.1] (4) When creating a report with subtotals, answering yes to the "Summary report only? (Y/N)" option can cause one of two known problems. The REPORT FORM will either print only the contents of the fields that are being totaled, or it will lock the system requiring a cold boot. [1.0, 1.1] title: REPLACE ALL version: 10 11 date: 10 Mar 1986 text: When used without any arguments, REPLACE ALL will return the error message "Internal error - illegal op code <no.>." The database file currently SELECTed will not be affected. The op code number and the number of messages vary from machine to machine. title: REPLACE IN ABBREVIATED FORM version: 10 11 date: 10 Mar 1986 text: If the REPLACE command is abbreviated, (REPL, REPLA, REPLAC), or REPLACE is used without an argument, the result may be the error message "illegal op code <no.>." The op code number is not relevant and varies from machine to machine. This Developer's Release will return the message "1 record replaced." title: REPLACE version: 10 11 date: 10 Mar 1986 text: With SET UNIQUE ON and an index file open, if you REPLACE the key field with a non-unique key, then REPLACE the key field again without repositioning the record pointer, dBASE III will return "No records replaced" and the computer will freeze. dBASE III will also freeze the computer if SET UNIQUE is ON and you APPEND a BLANK to an indexed file, and then do a REPLACE on the key field. This will occur whether or not the APPENDed record is unique or not. title: RELEASE ALL version: 10 date: 10 Mar 1986 text: There are instances in which the RELEASE ALL command does not appear to work. After executing a DO WHILE loop <n> times (the reported instances have occurred at three iterations), the message 'Out of memory variable memory' appears, though the memory limits are not exceeded. When RELEASE ALL is replaced with CLEAR MEMORY, the problem disappears. title: RECORD AS A RESERVED WORD version: 10 11 DR date: 10 Mar 1986 text: Avoid using any word of the form RECORD???? as a field name, because it can cause problems with several dBASE III commands. Specifically, the error message "Variable cannot be found" will occur if this field is used with either the AVERAGE, DISPLAY, LIST, REPLACE, or SUM commands. title: RECNO() VALUES version: 10 11 DR date: 10 Mar 1986 text: The following section of code shows that the RECNO() function returns the number of the last record accessed prior to closing the file. Even if the database file is closed, RECNO() retains its last value. USE Names GOTO 7 ? RECNO() 7 USE <--- Names is closed here. SELECT 2 USE Temp ? RECNO() 1 SELECT 1 * ---SELECT 1 has no database file in USE, but * ---RECNO() shows the last record value of * ---Names before it was closed. ? RECNO() 7 title: PCOL() AND SET MARGIN TO version: 10 11 date: 10 Mar 1986 text: PCOL() will not return the current printer head position when used in conjunction with SET MARGIN TO. Instead, it returns the current print position plus the margin offset. For example: STORE "Hello" TO var1 STORE "there" to var2 SET DEVICE TO PRINT @ 10,0 SAY var1 @ PROW(),PCOL()+1 SAY var2 SET MARGIN TO 10 @ 11,0 SAY var1 @ PROW(), PCOL()+1 SAY var2 RETURN prints the following: Hello there Hello there title: PARAMETERS version: 10 11 date: 10 Mar 1986 text: Misspelling the command PARAMETERS or omitting the command in a procedure file will produce an irrelevant error message. The error will usually be a syntax error on a command line that looks like a RETURN with a right arrow where the "R" should be. This error will also occur if an incorrect number of values are passed in the DO <filename> WITH <parameter list> command. For example: * Program..: Areacalc.PRG PARAMATERS length,width,area area = length * width RETURN * EOP: Areacalc.PRG * The following command is entered from the dot prompt. DO Areacalc WITH 6,4,0 Syntax Error ? A space following a memory variable in a PARAMETERS statement will return the "Unrecognized phrase/keyword in command" error message. The following command sequence demonstrates this anomaly. * Test.PRG PARAMETERS name name = "Steve" ^-------------there is a blank RETURN space after "name". . mvar = "John" . DO test WITH mvar Unrecognized phrase/keyword in command ? PARAMETERS name title: NUMERIC ACCURACY INCONSISTENCIES version: 10 11 date: 10 Mar 1986 text: There are some inconsistencies with the manner in which dBASE III handles numeric operations, especially comparisons. What follows are two examples that return unexpected results. EXAMPLE 1: . ? 4.1 - 2.1 2.0 . ? INT(4.1 - 2.1) = 2 .F. . ? INT(4.1 - 2.1) 1 EXAMPLE 2: . ? SQRT(100) 10.00 . ? SQRT(100) = 10 .F. . ? INT(SQRT(100)) = 10 .F. . ? INT(SQRT(100)) 9 The only reliable way to compare two numbers in dBASE III is to use the STR() function. For example: . ? STR(SQRT(100),10,2) = STR(10,10,2) .T. title: MODIFY STRUCTURE version: 11 date: 10 Mar 1986 text: It has been reported that MODIFY STRUCTURE will occasionally write a 00H in the delete marker position of a group of records in a database file, causing those records to be shifted one character to the right on LIST and DISPLAY. The records will appear normal with other commands such as EDIT and REPORT FORM. To date, this problem has only been reported on the IBM PC AT. If it occurs, DELETE and RECALL the offending records to restore the delete marker to its normal state, a 20H. (For more information on data record structures, see page D3-15.) For example: . USE Bad_file . LIST Record# NAME CODE PHONE 1 Joe AAA (111)111-1111 2 Mary BBB (222)222-2222 3 Tom CCC (333)333-3333 4 Alice DDD (444)444-4444 5 Betty EEE (555)555-5555 . GOTO 2 . DELETE NEXT 3 3 records deleted . GOTO 2 . RECALL NEXT 3 3 records recalled . LIST Record# NAME CODE PHONE 1 Joe AAA (111)111-1111 2 Mary BBB (222)222-2222 3 Tom CCC (333)333-3333 4 Alice DDD (444)444-4444 5 Betty EEE (555)555-5555 title: MODIFY REPORT version: 10 11 date: 10 Mar 1986 text: There is a problem in the REPORT FORM concerning the width of the column. Specifically, if a change in the field contents affects the column width, the field width will reflect the change. However, if the new value is not explicitly re-entered, the width will revert to the old value when another column is accessed or CREATE/MODIFY REPORT is exited. The REPORT FORM in the Developer's Release has been changed to rectify this problem. When a field's contents are changed, the column width will reflect the change only if the column width is increased. However, unlike versions 1.0 and 1.1, all changes to the column width are saved when CREATE/MODIFY REPORT is exited. title: MODIFY COMMAND (DEVELOPER'S RELEASE) version: DR date: 10 Mar 1986 text: In the Developer's Release, graphic characters will appear if you press Ctrl-@, Ctrl-C, or PgDn on the first line of text in MODIFY COMMAND. These characters are easily removed by editing. title: MEMO FIELDS, LISTING OR PRINTING AFTER A PREVIOUS FIELD version: 10 11 DR date: 10 Mar 1986 text: A problem displaying memo fields has been found in dBASE III by one of our users. The problem occurs when you try to list or print a memo field preceded by a field whose length will force the first line of the memo field to wrap around one or more times. Assume a file structure consisting of two fields: Structure for database: Example.DBF Field Field Name Type Width Dec 1 Field1 Character 100 2 Field2 Character 70 3 Comments Memo 10 ** Total ** 181 These display commands ? SPACE( 1 ), Comments ? Field1, Comments ? Field2, Comments ? Field1, Field2, Comments will all produce different results. If the total length of the fields preceding the memo field is 29 or above, the first line of the memo field will wrap around. The entire memo field will then be displayed in double space. Futhermore, if the total length of the fields preceding the memo field is long enough to force the first line of the memo field to be displayed starting on the second line of the display, then the entire memo field will be displayed in triple space. title: MEMO FIELDS, DISPLAYED FROM AN UNSELECTED AREA version: 10 11 DR date: 10 Mar 1986 text: An attempt to display a memo field from an unSELECTed work area will produce the error message "Unrecognized phrase/keyword in command". For example: SELECT A USE First SELECT B * ---The following database file has the character * ---field 'Name' and a memo field 'Notes'. USE Second SELECT A ? Second->Name <--- This works correctly. * * ---The following line returns the error message, * ---"Unrecognized phrase/keyword in command". ? Second->Notes * * ---The following line returns, * ---"No database in USE, enter filename:" LIST Second->Notes title: LOAD (DEVELOPER'S RELEASE) version: DR date: 10 Mar 1986 text: LOADable files must have filenames seven characters or less in length. Files having a names of eight characters will not be LOADed correctly. For example: LOAD Diskread CALL Diskread will return: File was not LOADed. when the CALL command is executed. The LOAD command produces no error message. If the filename above is changed to Dskread.BIN, the file is LOADed properly. title: LABEL LIMITATIONS version: 10 11 date: 10 Mar 1986 text: Certain LABEL forms lock up the system. This seems to happen with forms of 13 or more lines. Shorter forms will not print the last few lines when these lines contain a lot of text. title: JOIN WITH FILES CONTAINING MEMO FIELDS version: 10 11 date: 10 Mar 1986 text: The following anomalies may arise when JOINing database files that contain memo fields. 1) JOIN will not create the .DBT file for the target database when the active database file (that is, the file currently SELECTed) contains the memo field. The error message, "Memo file cannot be opened" will display when you attempt to USE the target file. 2) If the JOIN is executed with the FIELDS clause and the memo field is omitted, the target file will display the error message, "Memo file cannot be opened" when the target file is USEd. 3) If the file being JOINed WITH (that is, the un-SELECTed file) has a memo field and the active file does not, a .DBT file will be created for the target file, but the data contained in the memo field will not be transferred. Currently, there is no way to get the JOIN command to transfer memo field information into the target file. One work-around is to use the S-Join.PRG program which simulates the JOIN command with COPY and APPEND, and allows memo fields to be joined to the target file. (S-Join.PRG is in the February, 1985, issue of TechNotes, page D3-7.) If you do not want the memo fields copied over, COPY the active database file to another file using the FIELDS clause that does not include the memo field, USE that file, and then execute the JOIN. title: INKEY() version: DR date: 10 Mar 1986 text: The INKEY() function of the Developer's Release does not always read the leftarrow key as CHR(19). Running the following program will demonstrate that dBASE III will trap this key only rarely. i = 0 DO WHILE i <> 13 i = INKEY() ? i ENDDO When you run this program, you will notice that dBASE III treats the leftarrow key as a Ctrl-S, and will pause or start scrolling accordingly. Sometimes the key will be trapped and INKEY() will return 19; however, this is far less common than the former result. title: version: date: text: title: INDEXING WITH STR() OR SUBSTR() FUNCTIONS version: 10 11 DR date: 10 Mar 1986 text: Although the length argument of the STR() and SUBSTR() functions is optional, it must be included when either of these functions is used as part of an INDEX expression. Otherwise, the error message "Record is not in index" will occur when using either BROWSE, EDIT or GO/GOTO. title: INDEX WITH SET UNIQUE ON version: 10 11 DR date: 10 Mar 1986 text: INDEXing on a numeric field with SET UNIQUE ON may produce an incorrect count on the screen display. The actual index file is correct. The counter will be correct if you INDEX use the STR(fieldname,length). USE Test DISPLAY STRUCTURE Number of data records: 608 Field, Field name, Type, Width, Dec 1 One Numeric 4 0 2 Two Character 5 3 Three Character 5 ** Total ** 15 SET UNIQUE ON INDEX ON One TO Test 536 records indexed * incorrect count INDEX ON STR(One,4) TO Test1 42 records indexed * correct count title: INDEX AND BLANK DATES version: 10 11 DR date: 10 Mar 1986 text: A database file that is INDEXed on a date field will put blank dates at the bottom rather than the top of the index file. To work around this problem, use the following index expression instead of the date field: INDEX ON STR(YEAR(Date),4) + STR(MONTH(Date),2); + STR(DAY(Date),2) TO <filename> Using this expression, you will also be able to INDEX on date and character fields simultaneously. For example: INDEX ON STR(YEAR(Date),4) + STR(MONTH(Date),2); + STR(DAY(Date),2) + Last_name TO <filename> This command will create an index file that is in chronological order by Date and in alphabetical order by Last_name. title: FIND &MEMVAR WITH TRAILING BLANKS version: 10 11 date: 10 Mar 1986 text: FIND &memvar will return "No find" if there are trailing spaces following the memory variable. This occurs if the FIND is in a command file or issued at the dot prompt. Trailing blanks are concatenated to a macro when the FIND command is used. With the additional trailing blanks, the new character string might not be found. The following example uses a data file with the field NAME-C-10, indexed on this field, and a record with "RALPHxxxxx" in the Name field. The character "x" represents a blank. STORE "RALPH" TO memvar FIND &memvar<cr> (This FINDs record 1) FIND &memvarx<cr> (Still OK - "RALPHx"is record 1) FIND &memvarxxxxxx<cr> (No find - 6 trailing blanks exceeds field width) If less than the entire string is searched for, FIND will never work with the trailing blank. For example: STORE "RAL" TO memvar FIND &memvar<cr> (This finds record 1) FIND &memvarx<cr> (No find - "RALx" is not in the file) The workaround is to use the SEEK command. For example, SEEK memvar title: EXPONENTIATION DISPLAY version: 10 11 DR date: 10 Mar 1986 text: When raising an expression to a power in dBASE III, an overflow condition will arise if both the exponent and the expression are literal numbers greater than or equal to 10. For example: . ? 10^10 ************* To work around this problem, STORE either the expression or the exponent to a memory variable. For example: . num = 10 . ? 10^num 10000000000.00 title: EJECT AND SET PRINT ON WITH PRINTER OFF-LINE version: 10 11 DR date: 10 Mar 1986 text: EJECT and SET PRINT ON may lock the computer if the printer is not activated. The dBASE III User Manual warns that this may happen in the command section under both of these commands. If the printer power is on but the printer is off-line, issuing a <command> TO PRINT will give the following error message: Write fault error writing device PRN Abort, Retry, Ignore? This is an MS-DOS error message. Therefore, if you Abort, you will leave dBASE III and be left at the operating system level. The proper way to recover is to put the printer on-line and then Retry. title: EDIT version: 10 11 DR date: 10 Mar 1986 text: If BROWSE is used on an indexed file and is terminated with a Ctrl-Q or Ctrl-W and followed with an EDIT command, keys which advance or regress through the database file (PgUp, PgDn, uparrow, downarrow, Ctrl-E, Ctrl-R, Ctrl-C) will not work properly. Sometimes these keys will drop the user out of EDIT to the dot prompt. Other times they will move two or three records instead of one. The display will sometimes lock on the current record. These keys may also cause the pointer to be positioned at the next to last record in the index. title: DO WHILE WITH AN EXTRA ENDDO version: 10 date: 10 Mar 1986 text: If an extra ENDDO is added to a command file, an infinite loop will result. For example, the following program will execute until Esc is pressed: number = 0 DO WHILE number < 10 @ 10,10 SAY "Now at loop " + STR(number,2) STORE number + 1 TO number ENDDO ENDDO <--- This ENDDO has no matching DO WHILE. RETURN We recommend you use some method of indentation for the control structures: DO CASE...ENDCASE, DO WHILE...ENDDO, and IF...ENDIF to avoid this problem. This practice will make command files more readable, and will allow for quick visual checking for accuracy of nested control structures. In our example, two consecutive ENDDO statements with the same left margin is a definite indication that something is wrong. When using the command DISPLAY OFF in conjunction with TO PRINT and no specified scope in a command file, the DISPLAY will have an extra line-feed between each line. For example: SET HEADING OFF DO WHILE .NOT. EOF() DISPLAY OFF <Field1>, <Field2> TO PRINT SKIP ENDDO will yield: <value1> <value2> <----------- extra line-feed <value1> <value2> | <------- <value1> <value2> title: DO WHILE WITH RETURN version: 10 11 DR date: 10 Mar 1986 text: A RETURN statement inside a DO WHILE...ENDDO construction will not close the DO WHILE <condition> in the program as it does in dBASE II. Therefore, the <condition> will continue to be evaluated. For example: * A.PRG expA = "1" DO WHILE expA = "1" ? "Hi!" DO B ---------------> * B.PRG ENDDO expB = "2" * EOF: A.PRG DO WHILE expB = "2" ? "How are you?" expA = "X" RETURN ENDDO * EOF: B.PRG Executing A.PRG will cause an infinite loop. It appears dBASE III continues to test the condition of expB. In order to work around this, B.PRG should be written as follows: * B.PRG (revised). expB = "2" DO WHILE expB = "2" ? "How are you?" expA = "X" EXIT <----- Notice, the EXIT here, ENDDO RETURN <----- and the RETURN here. * EOF: B.PRG title: DO WHILE WITH SEMICOLON version: 10 11 date: 10 Mar 1986 text: When a DO WHILE conditional statement is continued to a second line with a semicolon, dBASE III tries to execute this second line the second time through the loop. When the ENDDO is encountered and the condition evaluates as true, program flow proceeds to this second line, resulting in the error message, "*** Unrecognized command verb." For example: * ---This program will give an error message * ---when "Y" is entered at the WAIT prompt. answer = 'Y' number = 1 DO WHILE number < 10; .AND. answer = 'Y' ? number WAIT '"Y" to continue ' TO answer number = number + 1 ENDDO If "Y" is entered at the WAIT prompt, dBASE III tries to execute ".AND. answer = 'Y'." However, if the semicolon is deleted and the line is allowed to wrap at column 67 in MODIFY COMMAND, execution flows correctly. title: DO WHILE WITH RESTORE version: 10 11 DR date: 10 Mar 1986 text: If a memory variable tested in a DO WHILE loop is recreated in the loop by RESTOREing the variable FROM a memory file, the loop will continue to run even after the condition no longer evaluates as true (.T.). The program below will run endlessly as long as the control variable is not the first entry in the memory file: var = .T. DO WHILE var RESTORE FROM Memfile <--- This overwrites var at the same memory location. var = .F. <--- This change is ignored if ENDDO the previous assignment statement changed the memory location of the variable. RESTOREing ADDITIVE ameliorates the problem. title: DO COMMAND FILE IN PROCEDURE ON TI PROFESSIONAL version: 11 date: 10 Mar 1986 text: With a procedure file open, attempting to DO any command file will result in a "*** Syntax error ***." For example, the command file below will produce the error. SET PROCEDURE TO Test1 DO Routine <---------------- Routine is a procedure DO Nonproc <-------------| in Test1. RETURN | |-- This is a separate command file. DO Routine will execute; however, DO Nonproc will produce the error message. This problem has been reported on the TI PRO version of dBASE III only. This will not produce an error on the IBM PC version. title: CTOD() version: 10 11 date: 10 Mar 1986 text: If a date type memory variable is created with a blank date and the month contains less than two spaces, the result will be 11/30/99. This occurs only if the month positions are incorrect. If the day and year positions are incorrectly initialized, the result is the expected, / / . Month position incorrect: date = CTOD(" / / ") ^ One space instead of two. The result: 11/30/99 Day and year positions incorrect: date = CTOD(" //") The result: / / title: CREATE AND ALIAS version: 10 11 date: 10 Mar 1986 text: After you CREATE a file, you must USE it again in order to establish the file name as the default alias name. Otherwise, the file name will have no alias name assigned to it. For example: CREATE File_one * ---Enter file structure. * ---Add a few records. DISPLAY STATUS * ---No alias name appears. SELECT 2 USE New_file SELECT File_one * ---Gives "Alias not found" message. title: CREATE <FILENAME> version: 10 11 DR date: 10 Mar 1986 text: (1) In dBASE III, a legitimate file name may contain up to eight characters consisting of an initial letter, and any combination of letters, numbers, and underscores. However, special characters ($,#,-,@,+,etc.) in the name will cause an error message if an <Alias> -> <Fieldname> is used. For example: USE Names SELECT 2 USE Test-it SELECT Names ? Test-it -> Fieldname Variable not found ? ? Test-it -> Fieldname (2) When creating a database file, if <RETURN> is pressed in the first field of the screen and editing is then resumed by pressing any key other than <RETURN>, the structure of the file saved will be corrupted. LISTing the STRUCTURE may lock the machine. [1.0, 1.1] title: COPY TO <FILENAME> SDF version: 10 11 date: 10 Mar 1986 text: If the database file being copied has a MEMO field, the data in the fields following the MEMO field will either not be copied or will be copied incorrectly. To work around this problem, use the FIELDS phrase in the COPY command. For example: COPY TO <filename> FIELDS <field list> SDF title: COPY TO <FILENAME> DELIMITED WITH WITHOUT DELIMITER version: 10 11 date: 10 Mar 1986 text: Using COPY TO <filename> DELIMITED WITH without a delimiter is not trapped as an error and will cause one of two problems: (1) if there is a space after the WITH, the error "Unrecognized phrase/keyword in command" is displayed; (2) if there is no space, the file is copied but the target file will contain all blank records. This problem was discovered in an attempt to build a comma separated file in which the character strings were not enclosed in delimiters. Currently, the COPY command does not have this capability. You can, however, create a comma separated file in which the character strings are delimited with a blank. The syntax is: COPY TO <filename> DELIMITED WITH BLANK title: COPY TO <FILENAME> DELIMITED version: 10 11 date: 10 Mar 1986 text: If a database file structure contains a large number of character or numeric fields with a length of one, the COPY TO <filename> DELIMITED command will produce unreliable results. For example, a file with 29 one-character fields will produce a text file with the following record: 1,"A","A","A",1,1,"A","A","A","A","A",1,1,1,1,1,1/ ,"A","A","A",",",",,,","," The last fields in the record have been garbled. title: COPY [STRUCTURE] TO <FILENAME> WITH SET SAFETY version: 10 11 date: 10 Mar 1986 text: The COPY [STRUCTURE] TO <filename> command ignores the status of SET SAFETY if it is issued in a command file. It will overwrite the target database file without warning. There are two work-arounds for this problem. The first work-around is to use the COPY FILE command instead. You will have to CLOSE the source database before this command can be used. The other work-around is to use the FILE() function to check for the existence of the target file before issuing the COPY TO command. For example: overwrite = .F. IF FILE( "Temp.DBF" ) @ 10,0 SAY "File already exists, overwrite it? (Y/N)"; GET overwrite READ ELSE overwrite = .T. ENDIF IF overwrite COPY TO Temp ENDIF title: CONFIG.DB WITH TEDIT OR WP version: 10 11 date: 10 Mar 1986 text: Config.db will not accept more than eight characters for WP or TEDIT. Any more than eight will be truncated. Attempting to use MODIFY COMMAND (or to edit a MEMO field) will briefly display the operating system message "Bad command or file name" and drop the user to the dBASE dot prompt (or to the edit screen). dBASE III warns the user that the filename is truncated when dBASE is initialized. For example: TEDIT=B:DFORMAT ^--- truncated To work around this problem, place the word processor in the same drive and directory or rename the wordprocessor with fewer characters. title: CONFIG.DB WITH SCOREBOARD version: 10 11 date: 10 Mar 1986 text: The entry SCOREBOARD=OFF has no effect if set in CONFIG.DB. SETing the SCOREBOARD OFF suppresses the display of status and error messages to line 0 . The SCOREBOARD setting can only be changed from a command file or the dot prompt with the command SET SCOREBOARD OFF. title: CLOSE PROCEDURE version: 10 11 DR date: 10 Mar 1986 text: If CLOSE PROCEDURE is included inside a procedure file, the procedure will stop running. The correct place to include the CLOSE PROCEDURE command is inside the calling program. title: CTRL-C WHILE PRINTING version: 10 11 date: 10 Mar 1986 text: If Ctrl-C is pressed while dBASE III is printing, the user is returned to the operating system. LIST TO PRINT, DISPLAY TO PRINT, and operations performed with SET PRINT ON and REPORT FORM TO PRINT are affected in this way. title: BROWSE version: 10 11 date: 10 Mar 1986 text: It appears that dBASE III does not release the memory used by BROWSE when the command is terminated. As a result, using many consecutive BROWSE commands will cause dBASE III to run out of memory and display the error message "Insufficient memory." The exact number will depend on how much memory is available. Once the error message occurs, the only way around the problem is to QUIT out of dBASE. CLEAR MEMORY will not solve the problem. title: BROWSE, APPENDING IN version: 10 11 DR date: 10 Mar 1986 text: Records seem to disappear when you use the APPEND option in BROWSE. To see this, go into BROWSE, then add a record, butdo not fill in all of the fields. The record number of the status line will be <n>. Press PgDn to add another record. The record previously added disappears and the record number will be one less than the previous number. Fill in some of the fields again, but this time press Return through therest of the fields.Check the record number, then press the Up Arrow key, then PgDn, and the missing record reappears with the proper record number restored. title: AVERAGE PRODUCES LINEFEEDS version: 10 11 date: 10 Mar 1986 text: See SUM. title: ASSIST WITH EXACTLY 27 FIELDS version: 10 11 date: 10 Mar 1986 text: Choosing an option in ASSIST that allows a FOR/WHILE clause (AVERAGE, DISPLAY, REPORT, etc...) on a database of exactly 27 fields, will not allow the last several fields to be used as part of the FOR/WHILE clause if the down arrow key is used to access those fields. Everything will appear fine until the last group of fields is displayed on the screen, at which point pressing the down arrow will take you to the next menu screen. Note that this anomaly only occurs on a database file with exactly 27 fields. It is possible to access the last several fields by way of the PgDn and down arrow keys; but, it is much easier to MODIFY the STRUCTURE of the database file to add another field which avoids the problem altogether. title: ASSIST version: 10 11 date: 10 Mar 1986 text: If the status of SET INTENSITY is OFF, ASSIST will be difficult to use. This is due to the fact that ASSIST relies on the options being in reverse video and yet neglects to change the status of the intensity parameter. title: APPEND FROM version: 10 11 DR date: 10 Mar 1986 text: (1) When using the APPEND FROM command, if the SDF file which is being read in has a 00 hex, any data for that record which appears after the 00 hex will not be added. If each record starts with a 00 hex, records will be APPENDed but they will all be blank. (2) If you APPEND FROM a DELIMITED text file that contains a space after a numeric field and before the comma, a zero will appear in the field following the numeric field. The blank space is apparently read as a separate field with a value of zero. Please note that Framework version 1.0 generates a text file of this format, which will be APPENDed incorrectly by dBASE III. Framework version 1.1 no longer terminates numeric fields in a text file with blanks. Such files will be APPENDed correctly by dBASE III. [1.0, 1.1] title: APPEND WITH A FORMAT FILE version: 10 11 date: 10 Mar 1986 text: Attempting a full-screen APPEND with a format file that does not match the database file will occasionally hang the computer or return the user to the dot prompt. title: APPEND version: 10 11 date: 10 Mar 1986 text: dBASE III allows the user to move back into previously existing records when using the interactive APPEND. If an index file is in use and key fields are edited in this manner,the index is no updated with the new key field values. The database file will have to be REINDEXed. title: APPEND (OR INSERT) version: 10 11 DR date: 10 Mar 1986 text: (1) If a file has so many fields that it requires more than one screen during full-screen APPEND (or INSERT), pressing Return in response to a numeric field on any screen other than the first will not display a zero in that field. This is strictly a cosmetic problem that will manifest itself only in the full-screen mode. That is, if you use CHANGE or EDIT, the field will appear blank, but ?, DISPLAY, and LIST will display the field as a zero. (2) When using full-screen APPEND (or INSERT), issuing a Ctrl-W or a Ctrl-End in the first character of a blank record will write the record to the file before leaving the full-screen mode. This is inconsistent with the original version (1.00) of the product. To work around this problem, use either Return, Ctrl-Q, or Esc to exit the full-screen mode. title: ADDITION version: 10 11 date: 10 Mar 1986 text: Adding 50 or more numbers together in a single command line will lock the computer, requiring a cold boot. For example, the command ? 1+1+1...+N, where N is the 50th number, will produce the correct answer, then freeze the computer. title: ?? COMMAND version: 10 11 date: 10 Mar 1986 text: Outputting a memo field with the ?? command in a program may produce undesirable results. The first time the command is encountered, the memo field will display correctly. Thereafter, only the first line of the memo field will display correctly. All subsequent lines will be offset to the right. For example, this program: DO WHILE .NOT. EOF() USE Test ?? Memo_fld SKIP ENDDO will output: The first memo field that prints will print out correctly. The second memo field will display like this if there is more than one line. ^---------The second and subsequent lines are displaced. title: & FUNCTION version: 10 11 DR date: 10 Mar 1986 text: The macro (&) function will not expand properly if it is followed by a space and parentheses. For example: STORE 'LIST FOR' TO x STORE 10 TO memvar &x Field1 = memvar will execute properly, but, &x (Field1 - memvar) * memvar = 0 will return the "*** Unrecognized command verb" error message. This problem can be avoided by terminating the macro-substituted memory variable with a period. For example, &x. (Field1 - memvar) * memvar = 0 will work. It is always a good idea to terminate a macro with a period. title: @...SAY...PICTURE "@Z" version: 10 11 date: 10 Mar 1986 text: The zero-suppress function, @Z, will not suppress the decimal point when it is used with a non-integer value of zero. To work around this display problem, use the following command sequence instead of the @Z function. IF STR( number, 5, 2 ) <> " 0.00" @ 10,0 SAY number ENDIF title: @...SAY...PICTURE LOGICAL VARIABLE version: 10 11 DR date: 10 Mar 1986 text: There is no PICTURE clause that applies to a logical variable in an @...GET command. However, if you attempt to use a PICTURE clause on a logical field or memory variable, dBASE III will not trap it as an error. When the READ is executed, dBASE III will not pause for user input, and the value of the field or variable will not be changed. One possible occurrence of this is when a memory variable is declared PUBLIC but is not initialized before an @...GET command. (dBASE III will automatically initialize a PUBLIC memory variable to a logical .F.) If the variable was not intended to be a logical variable, the above symptoms will manifest themselves. You may want to use the SPACE() function to initialize character variables and zero to initialize numeric variables. title: @...SAY...PICTURE "@A" AND "@!" version: 10 11 DR date: 10 Mar 1986 text: The A and ! PICTURE clause functions are mutually exclusive. That is, you cannot combine the two to make a new function that will limit data input to alphabetic characters and force the letters to uppercase. If A and ! are used together, only the second function will be in effect. For example: PICTURE "@A!" is equivalent to PICTURE "@!" PICTURE "@!A" is equivalent to PICTURE "@A" title: @...SAY...PICTURE "@X" AND "@C" version: 10 11 DR date: 10 Mar 1986 text: The C and X functions documented in the manual reference to the @...SAY command will always display positive numbers as credits (CR) and negative numbers as debits (DB). Use the following program segment if you need them to display in the reverse order (that is, positive numbers as debits (DB) and negative numbers as credits (CR)): DO CASE CASE number > 0 @ row,col SAY STR(number,17,2) + "DB" CASE number < 0 @ row,col SAY STR(-number,17,2) + "CR" OTHERWISE @ row,col SAY STR(number,17,2) ENDCASE title: @...SAY...PICTURE "$", ",", AND "9" version: 10 11 DR date: 10 Mar 1986 text: Using the template symbols "$", ",", and "9" in an @...SAY PICTURE clause may cause more than one dollar sign to be displayed on the screen. Specifically, if the value being displayed does not fill positions in the display string preceding the comma position, a dollar sign will be displayed in place of the comma. For example: mem = 123456 @ 10,0 SAY mem PICTURE "$999,999,999" @ 11,0 SAY mem PICTURE "$999,999,999,999" will output: $ $123,456 $ $ $123,456 The PICTURE template, ($), is intended to replace leading zeros in a numeric display with dollar signs. This means that dollar signs should always display in a fixed position format. To display a fixed position dollar sign leading a numeric expression with embedded commas, use two @...SAY commands, one to display the dollar sign and the other to display the numeric variable with the embedded commas. For example, mem = 1234.56 @ 10,10 SAY "$" @ ROW(),COL() + 1 SAY mem PICTURE "99,999.99" If you wish a leading dollar sign that is floating for numeric variables with embedded commas, a feature not directly supported by dBASE III, use the following command file to format the numeric variables. * Commas.PRG PARAMETERS mem mvar = SUBSTR( STR( mem, 9, 2 ), 1, 3 ) + ","; + SUBSTR( STR( mem, 9, 2 ), 4, 3 ); + SUBSTR( STR( mem, 9, 2 ), 7, 3 ) cntr = 1 DO WHILE SUBSTR( mvar, cntr, 1 ) $ ", " cntr = cntr + 1 ENDDO cnum = SPACE( cntr - 1 ) + "$" + SUBSTR( mvar, cntr ) @ 10,0 SAY cnum * EOP Commas.PRG STORE 1234.56 TO x DO Commas WITH x outputs: $1,234.56 This formula will work with numbers as large as $999,999.99. Larger numbers require that the length argument of the STR() function and the length and starting point arguments of the SUBSTR() function be changed to accommodate the larger number. For numbers as large as $999,999,999.99 the second line of the preceding program should be changed to: mvar = SUBSTR( STR( mem, 12, 2 ), 1, 3 ) + ","; + SUBSTR( STR( mem, 12, 2 ), 4, 3 ) + "," ; + SUBSTR( STR( mem, 12, 2 ), 7, 3 ) +; SUBSTR( STR( mem, 12, 2 ), 10, 2 ) This problem persists in the Developer's Release including both the PICTURE clause and the TRANSFORM() function. The work-arounds are a little bit easier given some new functions including TRANSFORM() itself. To display a numeric expression with a leading dollar sign in fixed position and embedded commas concatenate a dollar sign to the result of the TRANSFORM() of the numeric expression. For example, mem = 1234.56 @ 10,10 SAY "$" + TRANSFORM( mem, "99,999.99" ) To display a floating dollar sign leading a numeric expression with embedded commas, insert the dollar sign into the result of the TRANSFORM() function on the numeric expression. For example, mem = 1234.56 @ 10,10 SAY SPACE(10-LEN(LTRIM(TRANSFORM(mem,"99,999.99")))); ^--------- Length of the TRANSFORM() picture. + "$" + TRANSFORM(mem,"99,999.99") It is important to note that the first element in the SPACE() function argument must be the length of the TRANSFORM() picture. If, for example, the picture is "999", then the element is three. title: @...SAY...PICTURE "@(" version: 10 11 DR date: 10 Mar 1986 text: Displaying negative numeric memory variables with the @...SAY command and the PICTURE function "@(" to enclose negative numbers in parentheses, will not display the PICTURE correctly. Blanks will display between the beginning parenthesis and the memory variable contents. For example: number = 23.15 @ 10,10 SAY number PICTURE "@(" ( 23.15) The workaround is as follows: STORE STR( number, 12, 2 ) TO mem1 ^------------ Use an appropriate length and decimal value. STORE AT( "-", mem1 ) TO mpos @ 10,10 SAY SPACE(mpos-1) + "(" + SUBSTR(mem1,mpos+1) + ")" (23.15) title: @...SAY...GET version: 10 11 DR date: 10 Mar 1986 text: When entering numbers to the right of the decimal place of numeric fields, typing the period will sometimes cause the cursor to jump back to the beginning of the field. This problem manifests itself only when using a database file with one or more index files. The problem will also occur using APPEND, BROWSE, CHANGE, and EDIT. There are numerous work-arounds for this anomaly, but not all of them work all of the time. First, try reducing the number of buffers used in Config.sys to between 12 and 15. If this doesn't solve the problem and you are using an Autoexec.bat file, try removing the batch file from your boot disk. Finally, if there is a DEVICE=ANSI.SYS entry in Config.sys, try removing the entry. Note: You will need to reboot the machine in order for any of these changes to take effect. If text is printed to the screen with @...SAY, and then an @...SAY...GET is printed to the same line without erasing it first, characters from the previous text will appear between the SAY and the GET. For example: STORE '123' TO mem @ 10,0 SAY 'XXXXXXXXXXXX' @ 10,0 SAY 'A' GET mem displays: AX123XXXXXXX ^---------------- This should not be displayed. If you attempt to do a GET at a location greater than or equal to 80, the error message "SAY/GET position is off the screen" will be displayed. However, if you issue an @...SAY...GET that places the first character of the GET field in column 80, the machine will lock, requiring a warm boot. For example: STORE 'TEST' TO test @ 10,78 SAY 'x' GET test Note that this problem occurs only in this one instance. If the column coordinate in the above example is changed to 79, no error message is displayed and the GET wraps around to the next line on the screen. title: @...GET ALIAS IN FORMAT FILE version: 10 11 DR date: 10 Mar 1986 text: Any command that allows editing of a record will only operate in the SELECTed work area. However, attempting an @...SAY...GET using an ALIAS or SELECT to access another work area in a format (.FMT) file will not produce an error message. Instead, the entire line is suppressed, including the SAY statement. The Developer's Release of dBASE III will return the "Variable not found" error message if any attempt is made to GET a field from another work area. In versions 1.0 and 1.1 of dBASE III, the command: @ 10,4 SAY "Testing " GET B->Test in a format file will not display anything on the screen. Issuing this command from the dot prompt or in a command file will return "Variable not found." An alias name is acceptable in a SAY statement, even in a format file. @ 10,4 SAY "Testing " + B->Test will display properly. Notice that in the first example neither the SAY nor the GET pertaining to the second work area are displayed. 108 item(s) found